SharedUpdates folder empty after smc - stop or reboot
Created: 17 Jun 2010 | 12 comments
Full RU5 environment. GUPs working until reboot or smc -stop, either of which will empty the SharedUpdates folder. This is a problem because we lose all cached deltas.
Discussion Filed Under:
Comments
hi
have you customized your gup folder size?
Please don't forget to mark your thread solved with whatever answer helped you : ) Rafeeq
yes - to 1000. Is that a
yes - to 1000. Is that a factor?
hi
yes that the thing; uncheck that to a single gup
update it with defs
reboot and let us know the results..
Please don't forget to mark your thread solved with whatever answer helped you : ) Rafeeq
Hi Rafeeq Thanks for the
Hi Rafeeq
Thanks for the suggestion. We are just trying that now. I will let you know how we get on.
upgrade to RU
upgrade to RU 6
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009091611365448
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Yeah - thanks! Took ages to
Yeah - thanks! Took ages to get RU5 out to our clients everywhere and this issue is not specifically mentioned in RU6 Release Notes.
Bear in mind though that
Bear in mind though that isn't such a big deal, since the updates (in the case of AV defs) are only really valid on the day they are created, so there isn't really much point in caching them beyond that.
Sure, if you restart the GUP services every day, then it could become annoying that it purges everything, and thats why we changed the way RU6 works.
On the whole though, it shouldn't have a major effect on bandwidth.
Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint
Thanks Paul So just so I
Thanks Paul
So just so I understand this. If a client is turned off for a few days, to prevent it from pulling down the latest full definition via its GUP, can it not apply deltas cached in the GUP, so long as the GUP contains a full set of the deltas between the client's version and the current version?
Also, we have deployed a GUP policy with all defaults and it is still emptying the cache folder. Is there any way of preventing this behaviour without going to RU6. When we ultimately go to RU6, will it fix this issue - I cannot see this behaviour described in the RU6 Release Note?
The way the GUP and content
The way the GUP and content works at the moment means that unfortunately the client cannot take multiple delta's from the GUP or SEPM to get itself updated.
It has to be a single delta file, and it has to go from what the client has currently, to what it wants.
With this in mind, the content that the GUP is caching for other clients is effectively out of date after the day it was pulled and cached - it will never be used again. Depending on how long your client has been offline, a few days of delta shouldn't be that much. If its been off for a long time, then yes, its most likely going to pull the full definition set.
In terms of is there anyway to change the emptying behaviour in RU5, no there isnt.. Its by design. We changed the design with RU6 - it should be in the release notes, but I can't find it either... The only way to get the new behaviour is to upgrade I'm afraid.
Does that answer your questions?
Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint
RU5 GUP
Thanks Paul
I now understand that we cannot fix this in RU5, but do have one question. If our GUPs are governed by one LU Policy (DC*) and the clients by other LU policies, each of which explicitly names that group's GUP, would we have to upgrade all clients to RU6, or could we get away with just the SEPMs and the GUPs? In order to help the justification for RU6, can this issue and fix please be added to the Release Note.
I am still a bit confused about the other parts. If we configure the GUP to retain unused definitions for a number of days, can a client that has been turned off for that number of days or fewer (assuming the server has not been rebooted meanwhile) be updated by the deltas held in the cache by that retention setting? You said "it has to be a single delta file", then "a few days of delta shouldn't be that much" - which implies multiple deltas. The default setting is to retain unused deltas for 3 days (circa 9 deltas) - this seems to suggest that clients can update from multiple deltas. In other words a client that last checked in 5 days ago will be able to use cached deltas rather than asking the GUP to download a full definition from the SEPM. If the deltas are out of date after one day, I fail to see the purpose of the default setting to keep them for 3 days, especially as this can be increased. Ideally, it would be useful to have a document that clearly explains how these aspects of GUP functionality work, but I have been unable to find one. If such a document does exist, please could you p[ost a link to it.
Thanks again.
Problem still exists
Still struggling with this - have run some tests to see if I can understand what is happening, in the absense of any documentation. Any clarification of the questions in my last post would be appreciated.
Delta file is generated by
Delta file is generated by SEPM. If shared folder has the correct delta files for clients to use, the client should get that file through GUP.
If we configure the GUP to retain unused definitions for a number of days, can a client that has been turned off for that number of days or fewer (assuming the server has not been rebooted meanwhile) be updated by the deltas held in the cache by that retention setting?
---As far as I know, if the client's AV def is 0601001, and it needs to be upgraded to 060401, for example. And the delta file exists in shared folder, (0601001to0604001 delta file), then client can get it. But if the client has been offline for a long time, there is no 0601001to0604001 delta file but 0602001to0604001 delta file in shared folder, then client should ask SEPM to generate 0601001to0604001 delta file, then GUP get it and client get it again from GUP. If SEPM has no 0601001 definition, then GUP can only get full folder so as client does.
Another situation is GUP and client is in different group, and if clients in GUP's group and client group have different OS, 32bit or 64 bit, there will be an issue for downloading definition from GUP. This defect will be fixed in amber. But what I mean is only 32 bit in one group and 64 bit in another group, then the delta file generated will be different.
Would you like to reply?
Login or Register to post your comment.