We have our environment set to 90 revisions, how much space do we need to size our GUPs with?

That's up to you. You want the GUP to keep 90 as well?

how many will the gup keep by defualt? I don't belive we changed the default on GUP if there is such a setting?

Keeps 3 by default

You can configure multiple settings for the GUP, both space and number of revisions are two of them

Applies to all the version

Best Practices with Symantec Endpoint Protection Group Update Providers

http://www.symantec.com/business/support/index?page=content&id=TECH93813

How To Optimize Endpoint Protection for Branch Offices using GUPs, Load Balancing, and Location Awareness

http://www.symantec.com/business/support/index?page=content&id=TECH94122

By default, the GUP cache is set for 500MB and set to retain whatever they've downloaded for 3 days.

The cache may be insufficient if both a 32 and 64 bit client ask for the full virus defs (at 400MB each), so you might consider upping the cache size to 1GB.

The 3 day retention is not all that applicable, as (by default) clients always ask for the latest defs, therefore anything in the cache is redundant the moment the SEPM updates.

Hi,

By default the GUP will automatically purge content from its cache under two conditions:

If the content on the GUP grows larger than the configured Maximum disk cache size for content updates setting. The GUP will purge the oldest content by last accessed time until there is room for any new content.
If any individual content is older than the Delete content updates if unused setting, the GUP will remove that content.

However with the release of SEP 12.1 RU5 SEPM uses content storage optimization feaure. With this method I believe client GUP machine doesn't need more disk space to download contents.

Content Storage Optimization feature:

As part of the upgrade to SEPM 12.1 RU5, the SEPM converts all of the content from full definitions to delta definitions. This process is resource intensive and may take an extended period of time. After this process is completed, the SEPM will use significantly less disk space.

In a typical enterprise setup where 30 content revisions stored, the SEPM upgrade process must reduce 55GB of full content to under 2GB of delta content. This process requires significant resources to complete and is impacted by the performance of any available CPUs, CPU cores (physical/logical/hyperthreading), memory, and disks (I/O). On a server that performs multiple roles, stores larger numbers of content, or is otherwise resource constrained, this process may take a longer duration to complete.

Refer this article to find more info: The LiveUpdate content optimization and content storage space optimization steps take a long time to complete when upgrading to Symantec Endpoint Protection Manager 12.1 RU5

http://www.symantec.com/docs/TECH224055

That's not quite right.

The amount of space used on the GUP should remain the same, regardless of how defs are stored on the SEPM (in fact, I think it might use more).

The 12.1RU5 SEPM switches round how it stores defs, but it doesn't change the fact that it must have a client's defs in its repository in order to update it using deltas.  This means the SEPM still has to hand down the full defs to some clients (i.e. those running defs that the SEPM doesn't have a copy of anymore).

With full def sizes increasing everyday, the GUP cache size must increase to accommodate them.  Therefore, I'd recommend the cache should be large enough to store 1 copy of the full 32 bit AV defs, 1 copy of the full 64bit AV defs, plus a bit pf space for the other def types.

Leaving it at 500MB means only a single copy of the full AV defs can be cached.  Therefore it's possible to end up in a situation where a GUP must purge current defs to make room.

That was my understanding as well. Thanks for clarifying.

By default SEPM provides delta updates but If SEPM doesn't have a copy of requested definitions it would download full.zip & will give it to the client. To avoid this situation can increase the number content revision to keep on the SEPM itself & SEPM doesn't use high disk space now to store content revisions.

No problem 

I must admit though, I'm quite happy that the SEPM seems to hand down "combined" deltas for clients that need to skip a revision (i.e. any off overnight in UK), but a little concerned about this new-fangled "TempCache" directory.  Glad it's not handing out a series of incrementals!

To help illustrate, the system logs on a test client shows it successfully downloaded and updated its VirusDefs using a delta, and that the revision numbers in that delta skip rev. 140921001:

"Downloaded new content update from the management server successfully. 

Remote file path: http://SEPM:8014/content/TempCache/{07B590B3-9282-482f-BBAA-6D515D385869}/140921020/xdelta140921020_To_140922018.dax"

That still doesn't change the fact that full defs must still be used at times.  The changes only make it less likely to happen, and even then only if the SEPM grabs every def revision and stores them for a very long time.

Therefore, because requests for full defs still happen, the cache size on the GUP must accommodate it.

to SMLatCST...!