Endpoint SWAT: Protect the Endpoint Community

Is there a way to stop full updates from being distributed and only allow incrementals. We are having issues with SEP12RU4a causing slow network response
as clients on RU3 are causing requests for full update downloads and not incrementals, yet incrementals are available on the server. 

Why is there no notification/alert that incrementals are not being created or error in creating them?

There is no way to prevent full defs from being distributed, they are always available from the SEPM.

The only thing you can do is increase the number of revisions retained by the SEPM so that there's less chance a full update is required (i.e. the SEPM is able to create deltas for clients with ever older defs).

How many content revisions do you have set ?

The Symantec Endpoint Protection Manager (SEPM) can create delta definition packages for distributing just the changes made in the definitions since the last time a client was updated. This ability relies on the amount of content revisions maintained by the SEPM, which is configurable

How are virus definitions distributed from the Symantec Endpoint Protection Manager?

As the issue is network load, have you considered using GUPs and their bandwidth throttling settings to ensure the network load for definition distribution is kept to a minimum?

Incidentally, the distribution of the full defs instead of the deltas, is generally not considered an error, which is why no notification exists for it.

You must also bear in mind that each delta is for a specific definition as well.  Take the example below:

ClientA has defs of 3/19/2014 rev. 4
ClientB has defs of 3/19/2014 rev. 21

While the current latest defs on the SEPM are 3/19/2014 rev. 36

These are all different def revisions, and a different delta is required to upgrade ClientA to today's defs than ClientB.

Therefore, it's not a matter of "if there's a delta file, send it out".  It's more a matter of the SEPM deciding "can I create a delta file to upgrade this particular client from their current defs to the latest ones I have available?  If not, then the client can have the full defs".

And the rule which governs the SEPM's ablity to create defs is based on the number of definitions retained, divided by three (which is generally the number of def revisions released by Symantec everyday).  This means a SEPM with the default number of retained definitions (ten), is able to create delta files for clients which are up to ten revisions out of date (approximately 3 days).

Any client running a revision SEPM no longer holds, will receive the full defs.  This is because the SEPM cannot calculate the difference (delta) from defs it doesn't have, to the latest.

#EDIT#

In backup terminology (if that helps), each delta is a differential, not an incremental.

and How did you calculate that deltas are available? 

We have 85 revisions. Problem is not between SEPM and GUP - more that from GUP to remote site - bandwidth is too high due to full.zip downloads occurring to clients. Bandwidth throttling is needed between GUP and remote site - .

Yeah, it's unfortunate that there's no thottling between the GUPs and the clients, but that's because the intial idea (I think) was for the GUPs themselves to be on the same LAN as the remote clients (so throttling between GUP and SEPM is all that's required).

I take it you can't stick a GUP in your more remote sites?

Something I've mentioned in other posts, is the option of making all the clients in a remote site GUPs.  That way, you're not bound to any particular machine being on and available, and you benefit from the bandwidth savings and throttling options.

Perhaps worth a whirl?

Cant do that do to security restrictions. 

Given you have 85 revisions being stored on yoru SEPM, it should be able to provide delta updates to clients up to 4 weeks out of date.

Have you checked to see why clients are downloading the full defs?  Are they truly more than a month out of date and legitimately grabbing the full defs, or are they downloading the full defs to for some other reason (local def corruption perhaps)?

If it's legitimate, and you regularly have clients with defs more than 28days old, then your options are either to further increase the number of revisions to the point that these clients receive deltas, or look to implement the LUA (and use the throttling options in IIS as a Distribution Centre).

i agree to above comments from SMLatCST. you also should make sure the clients should be updated to the latest so that it does not ask for full def.

Machines are up to date with the latest definition when a full update gets downloaded . This happens on certain sites(perhaps network related) - Currently there is no way to 1)identify why clients are not receiving incrementals and/or full updates 2) Notifications of full updates or which client requested which definition.

There's nothing inbuilt, no.

However, if you enable the external logging option, you could (in theory) setup a fitler on your syslog server to look for logs that include the "full.zip" string (instead of the normal "xdelta*********.dax" string you'd expect from a delta update).

From the SEPM point of view, you can look for these anyway in Monitors -> Logs, using the below log search parameters:

Log Type: System

Log Content: Client Activity

Event Source: SYLINK