Endpoint Protection

Hello.

I've been using the same GUP's for about two years now with no problems to speak of. However, I've recently noticed that the SharedUpdates folder no longer resides in the default location of:

C:\Program Files\Symantec\Symantec Endpoint Protection\SharedUpdates.

My SEPM is running on version 12.1.4013.4013 Clients are mostly one version behind. I'm not sure but could it be that the location has changed with the recent upgrade of SEPM as this would co-inside with my theory. Please tell me if I'm barking up the wrong tree.

A separate issue but related; I've also had an issue for quite some time trying to update remote clients across a low speed WAN connection, so much so that a firewall rule is in place to stop network traffic to and from the GUP during business hours. I assume that outside business hours the GUP can and will request all the required updates and distribute them when the clients may a request.

I apologise for my basic explaination and terminology but if I need to explain anything further let me know.

Thank you in advance

SharedUpdates Folder could be found - 

SEP 11 - C:\Program Files\Symantec\Symantec Endpoint Protection\SharedUpdates

SEP 12.1 -

(32 bit machines) C:\Program Files\Symantec\Symantec Endpoint Protection\12.1.x.x.x\Bin\SharedUpdates.

(64 bit machines) C:\Program Files(x86)\Symantec\Symantec Endpoint Protection\12.1.x.x.x\Bin64\SharedUpdates

Tips For Installing SEP In A Low Bandwidth Environment

https://www-secure.symantec.com/connect/articles/tips-installing-sep-low-bandwidth-environment

How to Troubleshoot High Bandwidth usage issues in Symantec Endpoint Protection

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

SEPM & SEP Client bandwidth troubleshooting

https://www-secure.symantec.com/connect/articles/sepm-sep-client-bandwidth-troubleshooting

Many thanks for your reply James007.

You are right, with 12.1 the shared updates folder are in different location...

Since we cannot shedule updates from sepm to client or gup to client, your firewall rule would stop updating clients during bussiness hours, 

This is what happens when you set up a gup 

Client ---Request updates ----From ---SEPM ( interval period is called heartbeat, push mode / pull mode)

SEPM ---says to get it from GUP, this is the gup address ---

Client will use http://....gup address to get the updates from shared folder

Based on heartbeat this process will continue....

"Thumbs Up" to James above.  The GUP cache moved around a bit in v12.1.

As far as your remote clients go, I'm afraid it's not quite that simple.  The process of updating is all initiated by the SEP Client, rather than the GUP itself.  What this means with your GUP -> SEPM traffic restrictions, is that:

1. SEPM will update during the day as normal
2. SEP Client will check in and be told to download a def
3. SEP Client will ask GUP for it
4. GUP Cannot download it, and will retry
5. Out of hours, the GUP finally suceeds in downloading the earlier requested content
6. Out of hours, the SEP Client that originally requested the content downloads from the GUP

The only real issue here is if the SEP Client (that originally requested the defs) will even be online out of hours.  If not, then when it's switched on the next day, it will request a different set of defs as the SEPM will have updated again by then.  This will also fail to get down to the client if it's off out of hours, and so on and so on.

Not to mention that such a traffic restriction also prevent the GUP itself from updating during office hours.

Have you ever considered using the bandwidth throttling options to allow the GUP to download and cache content during the day, but ensure it doesn't severely impact the line?

Another option would be to use the LUA to push to a Distribution Centre (DC) on that remote site out of hours, and point the clients in the remote site to the DC for updates.  This should ensure they avoid the above described loop of never updating.

Further to the issue of GUP Content, I've noticed that my two GUP's have different amounts of update content even though both have the same policy settings in retaining 30 days worth of updates.

Could this have some thing to do with a the firewall rule in place preventing nework traffic for one GUP and not the other during business hours? Even so, both GUP's should contain the same amount of update content.

The policy states; 'Delete content updates if unused (days)' but within the GUP SharedFolder which has this firewall rule applied, there is only one days worth of updates. The other GUP SharedFolder has 30 days worth. Strange!

If anyone has any more information on this matter it would be gratefully received.

Thanks